x86/levelling: Provide architectural OSXSAVE handling to masked native CPUID
authorAndrew Cooper <andrew.cooper3@citrix.com>
Mon, 22 Aug 2016 16:50:55 +0000 (17:50 +0100)
committerAndrew Cooper <andrew.cooper3@citrix.com>
Thu, 1 Sep 2016 10:41:07 +0000 (11:41 +0100)
commit08e7738ec3644350fbac0325085baac6b3c7cd11
treeecab1571ae62db6ed20c77382c6cffc909a4f1ee
parent33b23e5ab319a6bf9bfd38c4d9268fa6d9d072c6
x86/levelling: Provide architectural OSXSAVE handling to masked native CPUID

Contrary to c/s b2507fe7 "x86/domctl: Update PV domain cpumasks when setting
cpuid policy", Intel CPUID masks are applied after fast forwarding hardware
state, rather than before.  (All behaviour in this regard appears completely
undocumented by both Intel and AMD).

Therefore, a set bit in the MSR causes hardware to be fast-forwarded, while a
clear bit forces the guests view to 0, even if Xen's CR4.OSXSAVE is actually
set.

This allows Xen to provide an architectural view of a guest kernels
CR4.OSXSAVE setting to any native CPUID instruction issused by guest kernel or
userspace, even when masking is used.

The masking value defaults to 1 (if the guest has XSAVE available) to cause
fast-forwarding to occur for the HVM and idle vcpus.

When setting the MSRs, a PV guest kernel's choice of OXSAVE is taken into
account, and clobbered from the MSR if not set.  This causes the
fast-forwarding of Xen's CR4 state not to happen.

As a side effect however, levelling potentially need updating on all PV CR4
changes.

Reported-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
xen/arch/x86/cpu/amd.c
xen/arch/x86/cpu/intel.c
xen/arch/x86/domctl.c
xen/arch/x86/traps.c